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(57) Abstract 



An Internet Web-based order entry and system (250) administration system is provided for ordering and fulfilling a suite of Web 
enabled applications (252). The system includes a capability for enabling customers to order and administer via the Internet. The system is 
easily accessed and invoked from a generic, off-the-shelf Web browser (250) and at the same time a system infrastructure is provided rhal 
enables secure initiation of order entry and system administration to customers from any computer terminal (20) having browser located 
anywiiere in die world. 
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AUTHENTICATION AND ENTITLEMENT FOR USERS 
OF WEB BASED DATA MANAGEMENT PROGRAMS 

The present invention relates in general to 
5 application software, and more specifically to Web- 
based system administrative software servicing local 
and a remote suite of applications in a communications 
network. 

System administrative software is generally 
10 known in the information systems industry. This type 
of software normally provides functions for adding and 
deleting users, file system management such as backups 
and version controls, and user security control. The 
system administrative functions provided by the known 

15 software, however, are usually limited to a specific 
computer platform or even a specific service product. 
For example, telecommunications service providers 
offer many different services which have been 
developed independently over time, and which operate 

20 on different computer platforms. Each of the 

applications associated with different services 
usually implements its own system administration 
functions for the related service product separately 
from the> others. Thus, when a customer needs to order 

25 or perfoarm administrative functions in more than one 
service product/ the customer is forced to exit the 
first application before beginning an operation on the 
second application. Moreover, when using the second 
service product, the customer must then reenter some 

30 of the same information previously entered while using 
the first service product. Therefore, it is desirable 
to have a centralized order entry and system 
administrative infrastructure for handling common 
functions and associated data for a number of product 

35 services. 

In addition, with the existing software, a 
customer support team interaction is usually necessary 
to complete the order entry and administrative 
process. Therefore, it is also desirable to have 

40 fully automated system administrative software, which 
automatically connects to the associated back-end 
systems and updates the back-end databases as 
necessary. Furthermore, the fully automated order 
entry system minimizes human intervention during the 

45 fulfillment, processing for each order entry requested 
by a customer, resulting in cost and time savings. 

In conventional systems, a connection is 
made with a large legacy system via a dial-up 
connection from a customer owned personal computer or 

50 workstation. This connection frequently, although not 
always, emulates a terminal addressable by the legacy 
systems. The dial-up access requires custom software 
on the customer workstation to provide dial-up 
services, communication services, emulation and/or 

55 translation services and generally some resident 
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custom form of the legacy application to interface 
with the midrange or mainframe computer running the 
legacy system. 

There are several problems associated with 
5 the approach. First, the aforementioned software is 
very hardware dependent, requiring multiple versions 
of software compatible with each of a wide range of 
workstations customers generally have. Therefore, 
extensive inventory for distribution becomes 

10 necessary. If the customer hardware platform changes 
through an upgrade, the software licensing issues must 
be renegotiated. Moreover, installing the software 
generally requires an intensive effort on the customer 
and the software support team before any reliable and 

15 secure sessions are possible. 

Secondly, dial-up, modem, and communications 
software interact with each other in many ways which 
are not always predictable to a custom application, 
requiring extensive trouble shooting and problem 

20 solving for an enterprise desiring to make the legacy 
system available to the customer, particularly where 
various telephone exchanges, dialing standards or 
signal standards are involved. 

. . Thirdly, although more businesses are 

25 turning' to the Internet to improve customer service 
and lower costs by providing Web -based support 
systems, when an enterprise desires to make more than 
one system available to the customer, the custom 
application for one legacy system is not able to 

30 connect to a different legacy system, and the customer 
must generally logoff and logon to switch from one to 
the other. The delivery technology used by the two 
legacy systems may be different, requiring different 
interface standards, and different machine level 

35 languages may be used by the two systems, as for 

example, the 96 character EBCDIC language used by IBM, 
and the 127 ASCII character language used by 
contemporary personal computers. Therefore, an 
integrated and unified Web-based system for providing 

40 an access to a number of different legacy systems in 
one session is desired. 

Finally, the security and entitlement 
features of the various legacy systems may be 
completely different, and vary from system to system 

45 and platform to platform. It is therefore, desired to 
provide connectivity to enterprise legacy systems over 
the public Internet, as the Internet provides access 
connectivity world wide via the TCP/IP protocol, 
without need to navigate various telephone exchanges, 

50 dialing standards or signal standards. 

The popularity of the public Internet 
provides a measure of platform independence for the 
customer, as the customer can run their own Internet 
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Web browser and utilize their own platform connection 
to the Internet to enable services. This resolves 
many of the platform hardware and connectivity issues 
in the customers favor, and leaves the choice of 
5 platform and operating system to the customer. Web- 
based programs can minimize the need for training and 
support since they utilize existing client software, 
i.e., a browser, which the user has already installed 
and already knows how to use. Moreover, there is no 

10 longer a need to produce and distribute voluminous 

hard copies of documentation including software user 
guides. Further, if the customer later changes that 
platform, then, as soon as the new platform is 
Internet enabled, service is restored to the customer. 

15 The connectivity and communications software burden is 
thus resolved in favor of standard and readily 
available hardware and the browser and software used 
by the public Internet connection. 

An Internet delivered paradigm obviates many 

20 of the installation and configuration problems 

involved with initial setup and configuration of a 
customer workstation, since the custom application 
required to interface with the legacy system can be 
delivered, via the pubic Internet and run within a 

25 standard Web-browser, reducing application 

compatibility issues to browser compatibility issues. 
The Web -based fully automated order entry system 
simplifies many of the fulfillment issues since the 
customers need not be provided with additional 

30 software and software user guides, other then a web 
browser. 

For the enterprise, the use of off-the-shelf 
Web browsers by the customer significantly simplifies 
the enterprise burden by limiting the client 

35 development side to screen layout designs and data 

presentation tools that use a common interface enabled 
by the Web browser. Software development and support 
resources are thus available for the delivery of the 
enterprise legacy services and are not consumed by a 

40 need for customer support at the workstation level. 

The present invention is to provide a Web- 
based, on-line application system for processing 
system administrative and order entry functions for an 
integrated suite of services and products over the 

45 Internet. For example, a suite of products and 

services may include personal communications services 
such as pagers, cellular phones, and voice mail, 
traditional wireline services, and Internet access. 
Other services include Toll Free Number Network and 

50 conferencing. Integrating these products and services 
and providing an online system for order entry and 
administration over the Internet allow improved 
flexibility to a customer when managing their 
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telecommunications accounts. For instance, the 
customer may effect desired changes in their accounts, 
in real time and instantaneously, by utilizing the 
system of the present invention. Moreover, the 
5 customer may instantaneously order additional services 
over the Internet via the system of the present 
invention. 

The present invention also handles the 
security and authentication requests from both the 

10 client and the server side of the applications 

implementing the suite of products and services. In 
this way, a single security profile may be maintained 
for a given customer, the security profile being 
included in a centralized database servicing the suite 

15 of disparate products and services. 

Furthermore, the present invention provides 
a real time transaction capabilities for notifying the 
client and server sides of applications implementing 
the suite of products and services, of the 

20 modifications effected by the customer using the 

system of the present invention. Upon receiving the 
notifications, the applications may update their data 
with the modifications effected, such that all data 
maintained about the customer are kept synchronized at 

25 all times. 

Additionally, the present invention includes 
a reconciliation process, which may be run 
periodically, for example, on a daily basis, for 
retrieving data from the mainframe database in order 
30 to refresh all data relating to customer information, 
such that the data stored in the present invention is 
kept up-to-date and synchronized with the mainframe 
system. 

Moreover, the present invention provides a 

35 fulfillment process for notifying a fulfillment house 
of all new customers added to the system. The 
fulfillment house then may send a welcome package 
including subscription information to the new 
customers as necessary. The present invention also 

40 includes a billing process for directing billing 

information to different billing streams as desired by 
the customer. 

The above features provided by the present 
invention are attained preferably with a Web-based 

45 centralized authentication and entitlement 

administration system for enabling a customer to enter 
orders over the Internet from a client terminal for 
one or more application services available at an 
enterprise Intranet. The system includes a client 

50 browser application running in a client workstation 
and providing an integrated interface to the one or 
more application services. The client browser 
application provides a graphical user interface for 
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interacting with the customer. Additionally, an order 
entry server located at the enterprise Intranet is 
provided. The order entry server communicates over 
the Internet with the client browser application to 
5 provide authentication and entitlement information 
associated with the customer. The client browser 
application uses the authentication and entitlement 
information associated with the customer and applies 
the authentication information in validating the 

10 customer before enabling the customer- to access the 
enterprise Intranet. The client browser application 
enables the customer to access only those application 
services to which the customer is entitled. An order 
entry object initiated via the client browser 

15 application is also included for enabling presentation 
of entry options for the customer, the entry options 
including adding a new order entry, modifying an 
existing order entry, and canceling an order entry. 
The order entry object further communicates customer 

20 entry of a specific entry option to the order entry 
server, thus allowing the customer to enter new 
orders, modify existing orders, and cancel orders for 
the application services within the customer 
entitlements ^via the integrated interface. 

25 Preferred embodiments of the present 

invention will now be described, by way of example 
only, with reference to the accompanying drawings in 
which: 

Figure 1 illustrates the software 
30 architecture component comprising a three- tiered 

structured- 
Figure 2 is a diagrsimmatic overview of the 

software architecture of the networkMCI Interact 

system; 

35 Figure 3 is an illustrative example of a 

backplane architecture schematic; 

Figure 4 illustrates an example client GUI 
presented to the client/customer as a browser web 
page ; 

40 Figure 5 is a diagram depicting the physical 

networkMCI Interact system architecture; 

Figures 6 and 7 illustrate an architectural 
overview for the system of the present invention; 

Figure 8 illustrates an example of a 
45 fulfillment letter sent to a customer; 

Figure 9 illustrates message class diagram 
showing relationship among the classes utilized in the 
present invention; 

Figure 10 is an illustrative example of an 
50 order entry process flow in the system of the present 
invention; 
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Figure 11 is an input process flow diagram, 
illustrating inputs to the system of the present 
inventions- 
Figure 12 is an output process flow diagram, 
5 illustrating outputs from the system of the present 
inventions- 
Figure 13 illustrates message formats used 
in transaction requests and responses communicated to 
and from the client and server applications in the 
10 system of the present invention; 

Figure 14 is a diagram illustrating data 
flow interface with the fulfillment house in the 
system of the present inventions- 
Figure 15 is a diagram illustrating data 
15 flow interface with the Reporting application; 

Figure 16 is a diagram illustrating data 
flow interface with the Toll Free Network Manager 
application; 

Figure 17 is a diagram illustrating data 
20 flow interface with the Broadband application; 

Figure 18 is an example of a StarOE main 
window which is launched from the "networkMCI 
Interact" home page; 

, ; Figure 19 illustrates a dialog box presented 
25 to a user from the StarOE main window for selecting an 
enterprise; 

Figure 20 illustrates an example of a 
new/modify users screen used for setting up new users 
or modifying options available to the existing users; 
30 Figure 21 illustrates a typical screen for 

setting up Toll Free Network Manager (TFNM) security; 

Figure 22 is a sample StarOE screen for 
adding and modifying reporting options which are used 
by the StarWRS; 
35 Figure 23 is a sample of the StarOE access 

setup screen; and 

Figure 24 illustrates a toll free network 
manager setup dialogue selected from the main window. 

40 An overview of the Web -enabled integrated system 

The present invention is one component of an 
integrated suite of customer network management and 
report applications using a Web browser paradigm. 

45 Known as the networkMCI Interact system {"nMCI 

Interact") such an integrated suite of Web -based 
applications provides an invaluable tool for enabling 
customers to manage their telecommunication assets, 
quickly and securely, from anywhere in the world. 

50 The nMCI Interact system architecture is 

basically organized as a set of common components 
comprising the following: 
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1) an object-oriented software architecture 
detailing the client and server based aspect of nMCI 
Interact; 

2) a network architecture defining the 

5 physical network needed to satisfy the security and 
data volume requirements of the networkMCI System; 

3) a data architecture detailing the 
application, back-end or legacy data sources available 
for networkMCI Interact; and 

10 4) an infrastructure covering security, 

order entry, fulfillment, billing, self -monitoring, 
metrics and support. 

Each of these common component areas will be 
generally discussed hereinbelow. 

15 Figure 1 is a diagrammatic illustration of 

the software architecture component in which the 
present invention functions. A first or client tier 
10 of software services are resident on a customer 
workstation 10 and provides customer access to the 

20 enterprise system, having one or more downloadable 
application objects directed to front -end business 
logic, one or more backplane service objects for 
managing sessions, one or more presentation services 
objects for the presentation of customer options and 

•25 customer requested data in a browser recognizable 
format and a customer supplied browser for 
presentation of customer options and data to the 
customer and for internet communications over the 
public Internet. Additional applications are directed 

30 to front -end services such as the presentation of data 
in the form of tables and charts, and data processing 
functions such as sorting and summarizing in a manner 
such that multiple programs are combined in a unified 
application suite . 

35 A second or middle tier 16, is provided 

having secure web servers and back-end services to 
provide applications that establish user sessions, 
govern user authentication and their entitlements, and 
communicate with adaptor programs to simplify the 

40 interchange of data across the network. 

A third or back-end tier 18 having 
applications directed to legacy back-end services 
including database storage and retrieval systems and 
one or more database servers for accessing system 

45 resources from one or more legacy hosts. 

Generally, the customer workstation includes 
client software capable of providing a platform- 
independent, browser -based, consistent user interface 
implementing objects programmed to provide a reusable 

50 and common GUI abstraction and problem -domain 

abstractions. More specifically, the client -tier 
software is created and distributed as a set of Java 
classes including the applet classes to provide an 
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industrial strength, object-oriented environment over 
the Internet. Application - specif ic classes are 
designed to support the functionality and server 
interfaces for each application with the functionality 
5 delivered through the system being of two -types: 1) 
cross -product, for example, inbox and reporting 
functions, and 2) product specific, for example, toll 
free network management or call management functions. 
The system is capable of delivering to customers the 

10 functionality appropriate to their product mix. 

Figure 2 is a diagrammatic overview of the 
software architecture of the networkMCI Interact 
system including: the Customer Browser (a.k.a. the 
Client) 20; the Demilitarized Zone (DMZ) 17 comprising 

15 a Web Servers cluster 24; the MCI Intranet Dispatcher 
Server 26; and the MCI Intranet Application servers 
30, and the data warehouses, legacy systems, etc. 40. 

The Customer Browser 20, is browser enabled 
and includes client applications responsible for 

20 presentation and front -end services. Its functions 
include providing a user interface to various MCI 
services and supporting communications with MCI's 
Intranet web server cluster 24. As illustrated in 
Figure, 3^ the client tier software is responsible for 

25 presentation services to the customer and generally 
includes a web browser 14 and additional object- 
oriented progreims residing in the client workstation 
platform 20. The client software is generally 
organized into a component architecture with each 

30 component generally comprising a specific application, 
providing an area of functionality. The applications 
generally are integrated using a "backplane" services 
layer 12 which provides a set of services to the 
application objects that provide the front -end 

35 business logic. The backplane services layer 12 also 

manages the launching of the application objects. The 
networkMCI Interact common set of objects provide a 
set of services to each of the applications. The set 
of services include: 1) session management; 2) 

40 application launch; 3) inter -application 

communications; 4) window navigation among 
applications; 5) log management; and 6) version 
management . 

The primary common object services include: 
45 graphical user interface (GUI); communications; 
printing; user identity, authentication, and 
entitlements; data import and export; logging and 
statistics; error handling; and messaging services. 

Figure 3 is a diagrammatic example of a 
50 backplane architecture scheme illustrating the 
relationship among the common objects. In this 
example, the backplane services layer 12 is programmed 
as a Java applet which may be loaded and launched by 
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the web browser 14. With reference to Figure 3, a 
typical user session starts with a web browser 14 
creating a backplane 12, after a successful logon. 
The backplane 12, inter alia, presents a user with an 
5 interface for networkMCI Interact application 

management. A typical user display provided by the 
backplane 12 may show a number of applications the 
user is entitled to run, each application represented 
by buttons depicted in Figure 3 as buttons 58a, b,c 

10 selectable by the user. As illustrated in Figure 2, 
upon selection of an application, the backplane 12 
launches that specific application, for example. 
Service Inquiry 54a or Event Monitor 54b, by creating 
the application object. In processing its functions, 

15 each application in turn, may utilize common object 

services provided by the backplane 12 . Figure 3 shows 
graphical user interface objects 56a, b created and 
used by a respective application 54a, b for its own 
presentation purposes. 

20 Figure 4 illustrates an example client GUI 

presented to the client/customer as a browser web page 
250 providing, for example, a suite 252 of network 
management reporting applications including: MCI 
Traffiq Monitor 2 52c; Call Manager 252f ; a Network 

25 Manager 252e and Online Invoice 252i. Access to 

network functionality is also provided through Report 
Requester 252b, which provides a variety of detailed 
reports for the client/customer and a Message Center 
252a for providing enhancements and functionality to 

30 traditional e-mail communications. 

As shown in Figures 3 and 4 , the browser 
resident GUI of the present invention implements a 
single object, COBackPlane which keeps track of all 
the client applications, and which has capabilities to 

35 start, stop, and provide references to any one of the 
client applications. 

The backplane 12 and the client applications 
use a browser 14 such as the Microsoft Explorer 
versions 4.0.1 or higher for an access and 

40 distribution mechanism. Although the backplane is 

initiated with a browser 14, the client applications 
are generally isolated from the browser in that they 
typically present their user interfaces in a separate 
frame, rather than sitting inside a Web page. 

45 The backplane architecture is implemented 

with several primary classes. These classes include 
COBackPlane, COApp, COAppImpl, COParm. and COAppFrame 
classes. COBackPlane 12 is an application backplane 
which launches the applications 54a, 54b, typically 

50 implemented as COApp. COBackPlane 12 is generally 
implemented as a Java applet and is launched by the 
Web browser 14. This backplane applet is responsible 
for launching and closing the COApps. 
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When the backplane is implemented as an 
applet, it overrides standard Applet methods initO, 
start 0, stopO and run(). In the initO method, the 
backplane applet obtains a COUser user context object. 
5 The COUser object holds information such as user 

profile, applications and their entitlements. The 
user's configuration and application entitlements 
provided in the COUser context are used to construct 
the application toolbar and Inbox applications. When 
10 an application toolbar icon is clicked, a particular 

COApp is launched by launchAppO method. The launched 
application then may use the backplane for inter- 
application communications, including retrieving Inbox 
data, 

15 The COBackPlane 12 includes methods for 

providing a reference to a particular COApp, for 
interoperation. For example, the COBackPlane class 
provides a getAppO method which returns references to 
application objects by name. Once retrieved in this 

20 manner, the application object's public interface may 
be used directly. 

As shown in Figure 2, the aforesaid objects 
will communicate the data by establishing a secure TCP 
messaging session with one of the DMZ networkMCl 

25 Interact Web servers 24 via an Internet secure 

communications path 22 established, preferably, with a 
secure sockets SSL version of HTTPS . The DMZ 
networkMCl Interact Web servers 24 function to decrypt 
the client message, preferably via the SSL 

30 implementation, and unwrap the session key and verify 
the users session. After establishing that the 
request has come from a valid user and mapping the 
request to its associated session, the DMZ Web servers 
24 re -encrypt the request using symmetric encryption 

35 and forward it over a second socket connection 23 to 

the dispatch server 26 inside the enterprise Intranet. 

A networkMCl Interact session is designated 
by a logon, successful authentication, followed by use 
of server resources, and logoff. However, the world- 

40 wide web communications protocol uses HTTP, a 

stateless protocol, each HTTP request and reply is a 
separate TCP/IP connection, completely independent of 
all previous or future connections between the same 
server and client. The nMCI Interact system is 

45 implemented with a secure version of HTTP such as S- 
HTTP or HTTPS, and preferably utilizes the SSL 
implementation of HTTPS. The preferred embodiment 
uses SSL which provides a cipher spec message which 
provides server authentication during a session. The 

50 preferred embodiment further associates a given HTTPS 
request with a logical session which is initiated and 
tracked by a "cookie jar server" 28 to generate a 
"cookie" which is a unique server -generated key that 
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is sent to the client along with each reply to a HTTPS 
request. The client holds the cookie and returns it 
to the server as part of each subsequent HTTPS 
request. As desired, either the Web servers 24, the 
5 cookie jar server 28 or the' Dispatch Server 26, may 
maintain the "cookie jar" to map these keys to the 
associated session. A separate cookie jar server 
28, as illustrated in Figure 2 has been found 
desirable to minimize the load on the dispatch server 

10 26. This form of session management also functions as 
an authentication of each HTTPS request, adding an 
additional level of security to the overall process. 

As illustrated in Figure 2, after one of the 
DKZ Web servers 24 decrypts and verifies the user 

15 session, it forwards the message through a firewall 

25b over a TCP/IP connection 23 to the dispatch server 
26 on a new TCP socket while the original socket 22 
from the browser is blocking, waiting for a response. 
The dispatch server 26 unwraps an outer protocol layer 

20 of the message from the DMZ services cluster 24, and 
re -encrypts the message with symmetric encryption and 
forwards the message to an appropriate application 
proxy via a third TCP/IP socket 27. While waiting for 
the proxy response all three of the sockets 22, 23, 27 

25 block on a receive. Specifically, once the message is 
decrypted, the wrappers are examined to reveal the 
user and the target middle- tier (Intranet application) 
service for the request. A first- level validation is 
performed, making sure that the user is entitled to 

30 communicate with the desired service. The user's 
entitlements in this regard are fetched by the 
dispatch server 26 from the StarOE server 49, the 
server component of the present invention, at logon 
time and cached. 

35 If the requestor is authorized to 

communicate with the target service, the message is 
forwarded to the desired service's proxy. Each 
application proxy is an application specific daemon 
which resides on a specific Intranet server, shown in 

40 Figure 2 as a suite of mid-range servers 30. Each 

Intranet application server of suite 3 0 is generally 
responsible for providing a specific back-end service 
requested by the client, and, is additionally capable 
of requesting services from other Intranet application 

45 servers by communicating to the specific proxy 

associated with that other application server. Thus, 
an application server not only can offer its browser a 
client to server interface through the proxy, but also 
may offer all its services from its proxy to other 

50 application servers. In effect, the application 

servers requesting services are acting as clients to 
the application servers providing the services. Such 
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mechanism increases the security of the overall system 
as well as reducing the number of interfaces. 

The network architecture of Figure 2 may 
also include a variety of application specific proxies 
5 having associated Intranet application servers 

including: a StarOE proxy for the StarOE application 
server 39 for handling authentication order 
entry/billing; an Inbox proxy for the Inbox 
application server 31, which functions as a container 

10 for completed reports, call detail data and marketing 
news messages; a Report Manager proxy capable of 
communicating with a system- specif ic Report Manager 
server 32 for generation, management and receipt 
notification of customized reports; a Report Scheduler 

15 proxy for performing the scheduling and requests of 
the customized reports. The customized reports 
include, for example: call usage analysis information 
provided from the StarODS server 33; network traffic 
analysis/monitor information provided from the Traffic 

20 view server 34; virtual data network alarms and 

performance reports provided by Broadband server 35; 
trouble tickets for switching, transmission and 
traffic faults provided by Service Inquiry server 3S; 
and toll 'free routing information provided by Toll 

25 Free Network Manager server 37. 

As partially shown in Figure 2, it is 
understood that each Intranet server of suite 30 
communicates with one or several consolidated network 
databases which include each customer's network 

30 management information and data. For example, the 

Services Inquiry server 36 includes communication with 
MCI's Customer Service Management legacy platform 
40 (a) . Such network management and customer network 
data is additionally accessible by authorized MCI 

35 management personnel. As shown in Figure 2, other 
legacy platforms 40(b), 40(c) and 40(d) may also 
communicate individually with the Intranet servers for 
servicing specific transactions initiated at the 
client browser. The illustrated legacy platforms 

40 40 (a) -(d) are illustrative only and it is understood 
other legacy platforms may be interpreted into the 
network architecture illustrated in Figure 2 through 
an intermediate midrange server 30. 

Each of the individual proxies may be 

45 maintained on the dispatch server 26, the related 
application server, or a separate proxy server 
situated between the dispatch server 26 and the 
midrange server 30. The relevant proxy waits for 
requests from an application client running on the 

50 customer's workstation 10 and then services the 
request, either by handling them internally or 
forwarding them to its associated Intranet application 
server 30. The proxies additionally receive 
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appropriate responses back from an Intranet 
application server 30. Any data returned from the 
Intranet application server 30 is translated back to 
client format, and returned over the internet to the 
5 client workstation 10 via the Dispatch Server 26 and 
at one of the web servers in the DMZ Services cluster 
24 and a secure sockets connection. When the 
resultant response header and trailing application 
specific data are sent back to the client browser from 

10 the proxy, the messages will cascade all the way back 
to the browser 14 in real time, limited only by the 
transmission latency speed of the network. 

The networkMCI Interact middle tier software 
includes a communications component offering three (3) 

15 types of data transport mechanisms: 1) Synchronous; 2) 
Asynchronous; and 3) Bulk transfer. Synchronous 
transaction is used for situations in which data will 
be returned by the application server 40 quickly. 
Thus, a single TCP connection will be made and kept 

20 open until the full response has been retrieved. 

Asynchronous transaction is supported 
generally for situations in which there may be a long 
delay in application server 40 response. 
Specifically,: a proxy will accept a request from a 

25 customer or client 10 via an SSL connection and then 
respond to the client 10 with a unique identifier and 
close the socket connection. The client 10 may then 
poll repeatedly on a periodic basis until the response 
is ready. Each poll will occur on a new socket 

30 connection to the proxy, and the proxy will either 

respond with the resultant data or, respond that the 
request is still in progress. This will reduce the 
number of resource consuming TCP connections open at 
any time and permit a user to close their browser or 

35 disconnect a modem and return later to check for 
results . 

Bulk transfer is generally intended for 
large data transfers and are unlimited in size. Bulk 
transfer permits cancellation during a transfer and 

40 allows the programmer to code resumption of a transfer 
at a later point in time. 

Figure 5 is a diagram depicting the physical 
networkMCI Interact system architecture 10. As shown 
in Figure 5, the system is divided into three major 

45 architectural divisions including: 1) the customer 

workstation 20 which include those mechanisms enabling 
customer connection to the Secure web servers 24; 2) a 
secure network area 17, known as the DeMilitarized 
Zone "DMZ" set aside on MCI premises double firewalled 

50 between the both the public Internet 25 and the MCI 
Intranet to prevent potentially hostile customer 
attacks; and, 3) the MCI Intranet Midrange Servers 30 
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and Legacy Mainframe Systems 4 0 which comprise the 
back-end business logic applications. 

As illustrated in Figure 5, the present 
invention includes a double or complex firewall system 
5 that creates a ''demilitarized zone" (DMZ) between two 
firewalls 25a, 25b. In the preferred embodiment, one 
of the firewalls 29 includes port specific filtering 
routers, which may only connect with a designated port 
on a dispatch server within the DMZ. The dispatch 

10 server connects with an authentication server, and 

through a proxy firewall to the application servers. 
This ensures that even if a remote user ID and 
password are hijacked, the only access granted is to 
one of the web servers 24 or to intermediate data and 

15 privileges authorized for that user. Further, the 
hijacker may not directly connect to any enterprise 
server in the enterprise intranet, thus ensuring 
internal company system security and integrity. Even 
with a stolen password, the hijacker may not connect 

20 to other ports, root directories or applications 
within the enterprise system. 

The DMZ acts as a double firewall for the 
enterprise intranet because the web servers located in 
the DMZ never store or compute actual customer 

25 sensitive data. The web servers only put the data 

into a form suitable for display by the customer's web 
browser. Since the DMZ web servers do not store 
customer data, there is a much smaller chance of any 
customer information being jeopardized in case of a 

30 security breach. 

As previously described, the customer access 
mechanism is a client workstation 20 employing a Web 
browser 14 for providing the access to the networkMCI 
Interact system via the public Internet 15 . When a 

35 subscriber connects to the networkMCI Interact Web 

site by entering the appropriate URL, a secure TCP/IP 
communications link 22 is established to one of 
several Web servers 24 located inside a first firewall 
25a in the DMZ 17. Preferably at least two web 

40 servers are provided for redundancy and failover 
capability. In the preferred embodiment of the 
invention, the system employs SSL encryption so that 
communications in both directions between the 
subscriber and the networkMCI Interact system are 

45 secure. 

In the preferred embodiment, all DMZ Secure 
Web servers 24 are preferably DEC 4100 systems having 
Unix or NT -based operating systems for running 
services such as HTTPS, FTP, and Telnet over TCP/IP. 
50 The web servers may be interconnected by a fast 
Ethernet LAN running at 100 Mbit/sec or greater, 
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preferably with the deployment of switches within the 
Ethernet LANs for improved bandwidth utilization. One 
such switching unit included as part of the network 
architecture is a HydraWEB™ unit 45, manufactured by 
5 HydraWEB Technologies, Inc., which provides the DMZ 
with a virtual IP address so that subscriber HTTPS 
requests received over the Internet will always be 
received. The HydraWEB™ unit 45 implements a load 
balancing algorithm enabling intelligent packet 

10 routing and providing optimal reliability and 

performance by guaranteeing accessibility to the "most 
available" server. It particularly monitors all 
aspects of web server health from CPU usage, to memory 
utilization, to available swap space so that 

15 Internet/Intranet networks can increase their hit rate 
and reduce Web server management costs. In this 
manner, resource utilization is maximized and 
bandwidth (throughput) is improved. It should be 
understood that a redundant HydraWEB™ unit may be 

20 implemented in a Hot/Standby configuration with 

heartbeat messaging between the two units (not shown) . 
Moreover, the networkMCI Interact system architecture 
afford^ Web "server scaling^ both in vertical and 
horizontal directions. Additionally, the architecture 

25 is such that new secure web servers 24 may be easily 
added as customer requirements and usage increases. 
The use of the HydraWEB™ enables better load 
distribution when needed to match performance 
requirements . 

30 As shown in Figure 5, the most available Web 

server 24 receives subscriber HTTPS requests, for 
example, from the HydraWEB"^ 45 over a connection 44a 
and generates the appropriate encrypted messages for 
routing the request to the appropriate MCI Intranet 

35 midrange web server over connection 44b, router 55 and 
connection 23. Via the HydraWEB™ unit 45, a TCP/IP 
connection 38 links the Secure Web server 24 with the 
MCI Intranet Dispatcher server 26. 

Further as shown in the DMZ 17 is a second 

40 RTM server 52 having its own connection to the public 
Internet via a TCP/IP connection 48. This RTM server 
provides real-time session management for subscribers 
of the networkMCI Interact Real Time Monitoring 
system. An additional TCP/IP connection 48 links the 

45 RTM Web server 52 with the MCI Intranet Dispatcher 
server 26. 

With more particularity, as further shown in 
Figure 5, the networkMCI Interact physical 
architecture includes three routers: a first router 49 
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for routing encrypted messages from the Public 
Internet 15 to the HydraWEB^ 4 5 over a socket 
connection 44; a second router 55 for routing 
encrypted subscriber messages from a Secure Web server 
5 24 to the Dispatcher server 26 located inside the 
second firewall 25b; and, a third router 65 for 
routing encrypted subscriber messages from the RTM Web 
server 52 to the Dispatcher server 26 inside the 
second firewall. Although not shown, each of the 

10 routers 55, 65 may additionally route signals through 
a series of other routers before eventually being 
routed to the nMCI Interact Dispatcher server 26. In 
operation, each of the Secure servers 24 function to 
decrypt the client message, preferably via the SSL 

15 implementation, and unwrap the session key and verify 
the users session from, the COUser object authenticated 
at Logon. 

After establishing that the request has come 
from a valid user and mapping the request to its 
20 associated session, the Secure Web servers 24 will re- 
encrypt the request using symmetric RSA encryption and 
forward it oyer a second secure socket connection 23 
to the dispatch server 26 inside the enterprise 
Intranet . 

25 As described herein, the data architecture 

component of networkMCI Interact reporting system is 
focused on the presentation of real time {un- priced) 
call detail data, such as provided by MCI's 
TrafficView Server 34, and priced call detail data and 

30 reports, such as provided by MCI's StarODS Server 33 
in a variety of user selected formats. 

All reporting is provided through a Report 
Requestor GUI application interface which support 
spreadsheet, a variety of graph and chart type, or 

35 both simultaneously. For example, the spreadsheet 

presentation allows for sorting by any arbitrary set 
of columns. The report viewer may also be launched 
from the inbox when a report is selected. 

A common database may be maintained to hold 

40 the common configuration data which may be used by the 
GUI applications and by the mid- range servers. Such 
common data includes but are not limited to: customer 
security profiles, billing hierarchies for each 
customer, general reference data (states, NPA's, 

45 Country codes), and customer specific pick lists: 
e.g., ANI's, calling cards, etc.. An MCI Internet 
StarOE server manages the data base for the common 
configuration of data. 

Report management related data is also 

50 generated which includes 1) report profiles defining 
the types of reports that are available, fields for 
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the reports, default sort options and customizations 
allowed; and 2) report requests defining customer 
specific report requests including report type, report 
name, scheduling criteria, and subtotal fields. This 
5 type of data is generally resident in a Report Manager 
server database and managed by the report manager. 

The Infrastructure component of the nMCI 
Reporting system includes mechanisms for providing 
secure communications regardless of the data content 

10 being communicated. The nMCI Interact system security 
infrastructure includes: 1) authentication, including 
the use of passwords and digital certificates; 2) 
public key encryption, such as employed by a secure 
sockets layer (SSL) encryption protocol; 3) firewalls, 

15 such as described above with reference to the network 
architecture component; and 4) non- repudiation 
techniques to guarantee that a message originating 
from a source is the actual identified sender. One 
technique employed to combat repudiation includes use 

20 of an audit trail with electronically signed one-way 
message digests included with each transaction. 

Another component of the nMCI Interact 
infrastructure includes order entry, which is 
supported by: the present invention, the Order Entry 

25 ("StarOE") service. The general categories of 
features to be ordered include: 1) Reporting, 
including inbound traffic standard, inbound traffic 
call detail, inbound traffic exception, inbound 
traffic real time monitor reports, priced reports, and 

30 priced call detail reports; 2) Broadband, including 
basic, standard, enhanced with SNMP, enhanced with 
adhoc, premium, dedicated SNMP, and dedicated SNMP 
with adhoc; 3) Toll Free Network Manager; and 4) Call 
Manager. The order entry functionality is extended to 

35 additionally support 5) Event Monitor; 6) Service 

Inquiry; 7) Outbound Network Manager; and, 8) Online 
invoicing . 

The self -monitoring infrastructure component 
for nMCI Interact is the employment of mid- range 

40 servers that support SNMP alerts at the hardware 
level. In addition, all software processes must 
generate alerts based on process health, connectivity, 
and availability of resources (e.g., disk usage, CPU 
utilization, database availability) . 

45 The Metrics infrastructure component for 

nMCI Interact is the employment of mechanisms to 
monitor throughput and volumes at the Web servers, 
dispatcher server, application proxies and mid- range 
servers. Metrics monitoring helps in the determination 

50 of hardware and network growth. 

To provide the areas of functionality 
described above, the client tier 10 is organized into 
a component architecture, with each component 
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providing one of the areas of functionality. The 
client- tier software is organized into a "component" 
architecture supporting such applications as inbox 
fetch and inbox management, report viewer and report 
5 requestor, TFNM, Event Monitor, Broadband, Real-Time 
Monitor, and system administration application. 
Further functionality integrated into the software 
architecture includes applications such as Outbound 
Network Manager, Call Manager, Service Inquiry and 
10 Online invoicing. 

StarOE 

•The present invention is directed to a 
15 system administration and order entry component 

(StarOE) of the above described integrated suite of 
customer network management and report application, 
referred to as the "networkMCI Interact". The system 
of the present invention, the StarOE, is used to 
20 order, fulfill, and bill for, as well as administer, 
the suite of network applications, providing a 
horizontal service for use by all applications. The 
applications communicate to StarOE for all 
authentication, entitlement and system administration 
25 as well as order entry services. StarOE centrally 
processes these service requests for the individual 
applications by providing all order entry and security 
information for the "networkMCI Interact" suite of 
applications . 

30 The security information which the StarOE 

maintains and provides describes identification, 
authentication and access control used in the suite of 
applications. All access to the "networkMCI Interact" 
is controlled by userids and passwords. In addition, 

35 individual users are specifically granted access to 
only the necessary system objects, i.e., file, 
programs, menus, reports, etc. Access to these 
individual objects are based upon the customer 
privilege models, referred to as entitlements, stored 

40 in a StarOE database. Thus, all information regarding 
customers and their access levels for each product in 
the suite of network applications to which the 
customers have subscribed are stored in a customer 
security profile database local to the StarOE. 

45 Accordingly, StarOE provides the ability to prevent 
unauthorized, non- customer access to "networkMCI 
Interact" data and applications; ability to allow 
customers to access multiple enterprises with one 
userid; ability to restrict authorized users to 

50 specific Intranet applications and databases based on 
applications ordered by the customer; and the ability 
for users to restrict view and/or update capabilities 
within an application or data set, i.e., customers may 
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provide or restrict views of their "enterprise" data 
to subgroups within their organization. 

By utilizing the system of the present 
invention, customers no longer have to place manual 
5 calls to order entry hubs when requesting order 

transactions. For example, users may be added to the 
system without an enterprise's support team 
intervention. In sum, customers may manage their 
communications services in a secure environment and 

10 also, for example, monitor their network traffic via 
the Internet, as well as have a capability to add 
products and services to their account, in an 
automated fashion and all in one session without 
having to enter and exit the individual application 

15 services separately, and without having to contact a 
customer support representative. 

Figures 6 and 7 illustrate an architectural 
overview of the administration and order entry system 
of the present invention, i.e., StarOE. The StarOE 

20 includes a server 202 typically resident in a midrange 
computer, and a client application 204 running in a 
user platform having a Web browser, hereinafter 
referred to as a StarOE client application. The 
StarOE processes a number of transaction requests 

25 relating to authentication and entitlements, from 

other application services, both from the client and 
the server 208 sides of the network. In addition, the 
StarOE server 202 receives transaction requests from 
the StarOE client. The transactions are typically 

30 message driven and comprise requesting transactions 
and response transactions. The transaction messages 
will be described in detail in reference to Figure 13. 
The StarOE server 2 02 responds to the requests by 
formulating transaction responses and transmitting 

35 them to the requesting servers and clients. 

The StarOE client application 

The StarOE client application 204 is 
40 typically a Web-based GUI interface running in a World 
Wide Web browser (Microsoft Internet Explorer 4.0.1 or 
higher) , and implemented accordingly and conforming to 
a standard defined for the GUI interface for the 
integrated suite of customer network management and 
45 report applications ( "networkMCI Interact"). The 

client application's user interface is consistent with 
other products and services under the suite of network 
applications . 

The client browser application 204 generally 
50 includes a Web browser and Java applications and 
applets for providing a common Web -based GUI for 
interacting with customers at the front-end side. A 
backplane unit, a backbone for applications running in 
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the client platform is typically launched as a Java 
applet from a Web page, i.e., the "networkMCI 
Interact" home page (Figure 4) . The StarOE client 
application may then be invoked from the home page by 
5 the backplane unit at customer's initiation. 

When a customer launches the StarOE 
application from the home page, the main window as 
illustrated in Figure 18, is presented. From this 
main window 500, a customer may select to order and 
10 fulfill application services, request user id's, and 
create user security profiles for the "networkMCI 
Interact" suite of applications. The main window 500 
includes a menu bar 5 06 with options to perform 
various StarOE tasks. The main window also includes a 

15 toolbar 504, common to all "networkMCI Interact" 

applications. The toolbar 504 has buttons that also 
perform the various StarOE functions. Typically, the 
user list is presented, i.e., displayed as a tree 502, 
within the main window 500. 

20 The menu options 506 include: file menu 

options which includes a select enterprise option for 
allowing administrators to open a user list for a 
different enterprise, or add a new enterprise to their 
enterprise list, print option, and exit option which 

25 shuts down the StarOE application; edit menu option 

which includes add new application, modify, and delete 
options; options menu which enables a global security 
setup for the toll free manager application; view menu 
which includes options to refresh the screen by 

30 retrieving the latest user list for the opened 

enterprise from the StarOE server and displaying the 
list on the screen, to expand all nodes in the user 
list, and to collapse all nodes in the user list; and 
help menu option which launches the help engine with 

35 StarOE help text. The toolbar 504 also includes the 
options for a select enterprise, refresh, expand all, 
collapse all, print and help options. 

A typical process flow logic for StarOE 
client application starts with the home page launching 

40 the StarOE client and passing a reference to a common 
user information object. This object includes the 
user id, and the default enterprise for that user. 
The main window 500 having the menu options 506 and 
the toolbar 504 is then presented. The StarOE client 

45 application then sends a "get StarOE security" message 
by including user id, enterprise id, and the StarOE 
application code in the message. The StarOE server 
202 returns racf id, an access level representing 
whether the user is an external admin, a member of an 

50 account team, an internal admin, or a customer support 
admin, for example. If the user that launches the 
StarOE application is an external admin, the user list 
is displayed immediately since external administrators 

-20- 



wo 99/15989 PCT/US98/20159 



may view only one enterprise. For external 
administrators^ an enterprise name is retrieved from 
the StarOE server 202 by sending and receiving a "get 
user enterprise list" transaction request and 
5 response. 

If the user is not an external 
administrator, then a dialog is presented for the user 
to select which enterprise to view. When user selects 
an enterprise to view, a "get user list" message 

10 having enterprise id is sent to the StarOE server 2 02 
to retrieve a list of user ids, a list of applications 
for each user, an access type for each application, 
and reporting types for StarWRS (e.g.. Toll Free, 
Vnet, Vision, CVNS) . The client application also 

15 sends a "get application list" message to retrieve 
from the StarOE server 202 a list of application 
codes, description, and an application array position. 
The user list is then displayed within the main window 
as shown at 502. 

20 Every user list has a New User node 5 02a as 

the first node under an enterprise 502b. This node 
may be selected to order a new user. An existing user 
node 502c may be selected to edit and add new 
applications- for that user, when an existing user 

25 node 502c is selected, the edit/add new application 
options on the menu 506 is enabled and disabled 
according to what applications the user already has. 
An existing user application node 502d may be selected 
to edit/modify/delete options within the application. 

30 Figure 19 illustrates a dialog box 510 

presented to a user for selecting an enterprise. This 
dialog box is displayed when the user chooses the 
select enterprise menu option or toolbar button. It 
may also be displayed automatically when the StarOE 

35 client application determines that the user is not an 
external user who, therefore, may have access to 
multiple enterprises ids. The purpose of the dialog 
is to allow the administrator to work with a different 
enterprise, as well as add an enterprise to their 

40 enterprise list. 

Typically, the dialog is presented with a 
list of enterprises to which that the user has access 
as shown at 510. An object constructor takes a user 
id as an argument and formats and sends a "get user 

45 enterprise list" message to the StarOE server 202. 

The StarOE server 2 02 returns the list of enterprises 
for the user to the StarOE client application 204 
which then displays the list as shown at 510. The 
select button allows the administrator to add an 

50 enterprise by causing the client application 204 to 
send an "add user enterprise" message to the StarOE 
server 202. The search button 514b allows the 
administrator to search for an enterprise by entering 
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either an enterprise id or part of the enterprise name 
with wild card characters. A selection of the search 
button 514b also causes the client application 204 to 
send a "get enterprise list" to the StarOE server 202. 
5 The delete button 514c when- pressed, removes the 

enterprise from the administrator's enterprise list. 
The cancel button 514d is used to return control to 
the main window 500. 

Figure 20 illustrates an example of a 

10 new/modify users screen 520 used for setting up new 
users or modifying various options available to the 
existing users. The screen is typically presented as 
a modal dialog displayed on top of the main window 
when a user node 502c is selected and the modify 

15 option is chosen from the main window 500. It may 

also be presented when the new user node 502a and the 
add new application menu option is chosen. This 
screen 520 is generally presented by the client 
application 204 invoking a class object for handling 

20 the new/modify user functionality. On construction of 
this object, an add/modify flag is initialized. If an 
add flag is set, an empty screen is displayed with an 
empty user profile in memory and a new password is 
generated and displayed in the password field as shown 

25 at 522.' If a modify flag is set, the client 

application 204 via the object it invoked, formats and 
sends a ''get user info" message to the StarOE server 
202. When a response to the message is received, the 
client application 204 stores user profile received 

30 with the response from the StarOE server 202 in 

memory, and populates the fields on the screen 520 
accordingly. The application setup button 524a may be 
enabled during an add user process for presenting the 
appropriate application's security setup screen. The 

35 cancel button 524c generally prompts the user for 
confirmation to cancel, and returns control to the 
main window 500. When a submit button 524b is 
pressed, the user profile information is sent to the 
StarOE server 202 using the "set user info" message. 

40 This message is always sent during an add process. 

During a modify process, this message is sent to the 
StarOE server 202 only if any changes were entered by 
the user. When the StarOE server 202 receives the 
message, it returns an acknowledgment message. The 

45 client application 204 then returns control to the 
main window 500. 

During the StarOE add or modify procedure 
described above, security information regarding 
customer entitlements for application services may 

50 also be initialized. Figure 21 illustrates a typical 
screen for setting up Toll Free Network Manager (TFNM) 
security information. This screen 530 is typically 
displayed when TFNM is ordered or modified. The corp 
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ids may be displayed in a tree format as shown at 532. 
If a corp id is part of the user's profile, a racf id 
may be displayed with the corp id in the tree. The 
user id is typically displayed in the title bar. A 
5 user's TFNM security profile includes at least one 

corp id, with each corp id having an associated racf 
id. The racf ids 534 are manually entered for each 
corp id, A default corp id is chosen for each user. 

A setup security object typically handles 

10 the process of setting up security for each 

application. A constructor for this object 
initializes the user id and a modify flag as passed in 
from the StarOE client application 204. The object 
retrieves the toll free hierarchy from the StarOE 

15 server 202 using the "get hierarchy" message. The 
client application 204 sends the enterprise id, and 
tollfree flag in the request, and the StarOE server 
202 returns the list of tollfree corp ids for the 
enterprise. If the modify flag is set, a "get 

20 security" message is sent to the server 202 to 

retrieve the user's TFNM security profile. As the 
tree is loaded with each toll free corp id 532, racf 
id 534 is entered by a user. When the submit button 
is pressed, the setup security object calls its send 

25 security method which causes the formatting and 

sending of "setTFNM security" message to the StarOE 
server 202. When the StarOE server 202 receives the 
message, it sets the security accordingly for the TFNM 
application. 

30 The StarOE system is also utilized to order, 

for example, to add or modify, various reporting 
options used during report generation by the StarWRS. 
The StarWRS application is a reporting mechanism for 
the "networkMCI Interact". Figure 22 is a sample 

35 StarOE screen 540 for adding and modifying reporting 
options which are used by the StarWRS. The StarOE 
displays the toll free hierarchy for security setup 
when toll free reporting is ordered or modified. The 
hierarchy includes a list of corp ids for a given 

40 enterprise, with each corp id 542 having a list of 
toll free numbers 544 under it. The list may be 
displayed in a tree format, similar to the TFNM 
security display 530. The reporting options at the 
toll free number level include unpriced reports, 

45 unpriced call detail, and real time monitor reports. 

Typically, a user's toll free reporting 
security profile includes at least one toll free 
number with at least one reporting option associated. 
The client application 204 generally invokes an object 

50 to handle the reporting option changes and passes in 
the user id and a modify flag. This object then 
retrieves the toll free hierarchy from the StarOE 
server 202 using the "get hierarchy" message. The 
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Client application 204 sends the enterprise id, and 
toll free flag in the request, whereby, the server 202 
returns the list of toll free corp ids for the 
enterprise. If a modify flag is set, a "get tollfree 
5 security" message is sent to the server to retrieve 
the user's toll free security profile. 

As each corp id is expanded, a ''get tollfree 
numbers" message is sent to the server 2 02 asking for 
all the numbers for the corp id selected. As each 

10 toll free number is added, a search in the user's 

profile for that number is conducted. If the number 
is found, the report options are added next to number 
text as shown at 54 6. Furthermore, if the number has 
been deactivated, a text "<inactive>" , for example, is 

15 added to the display as shown at 548. The inactive 

numbers are not modifiable. When the unpriced reports 
or unpriced call detail check boxes are changed, the 
text next to the toll free numbers selected reflects 
the state of the check box. The check boxes depict 

20 report options to which a user has access for toll 

free numbers. When more than one toll free number is 
selected, the check boxes are marked unchecked. When 
a submit button is pressed, the object calls its send 
security-; class method which causes the formatting and 

25 sending of a "set user tollfree security" message to 
the StarOE server 202. 

In addition to handling the orders for the 
suite of applications in the "networkMCI Interact", 
the order entry application, StarOE, may also be 

30 modified via the StarOE. Figure 23 is a sample of the 
StarOE access setup screen 550. The StarOE order 
object is created any time the StarOE node for an 
existing user is selected and the edit/modify menu 
option is selected from the main window 500. It may 

35 also be presented when the Application Setup button 
524a is pressed on the new user screen 520. 

Typically, the StarOE client application 2 04 
invokes a class object for handling the StarOE order 
functionality. The object's constructor initializes 

40 the user id of the user being configured, a modify 
flag, and the StarOE level of the logged in 
administrator as passed in from the client application 
204. User level options 552 may be set according to 
the administrator's StarOE access level. The 

45 administrator may not select an access level that is 
higher than the present level. For example, an 
account team may not change a user's access to an 
internal level, when a submit button 554 is pressed, 
the racf id is checked for a valid value, then the 

50 object calls the iSendSecuri ty ( ) method which formats 
and sends a "set StarOE Security" message to the 
StarOE server 202. 
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The Racf id represents the user's mainframe 
id. The user level is used to determine the level of 
access the user has within StarOE. An administrator 
may have one of the following access levels: external, 
5 account, and internal. External administrators have 
access to view and update all users under their 
enterprise. They may be able to modify a user's 
security for the applications that they have 
permission for administration. These users may not be 

10 allowed to order applications, but may need to request 
their orders through their account team 
representative. An account administrator is used for 
account team members. This level of user may have the 
ability to view user lists for multiple enterprises, 

15 and configure a user's application access information. 
Internal users have the same privileges as account 
administrators, as well as the ability to order new 
applications for new and existing users. Internal 
administrators also have the ability to setup global 

20 security information for each application. The 
internal administrators have access to multiple 
enterprise ids. 

The StarOE is also utilized to setup global 
security ; for ^ corp ids. The purpose for. setting up 

25 global security is to allow the administrator to make 
corp ids available for inclusion in users' profiles. 
Figure 24 illustrates a toll free network manager 
setup dialogue selected from the main window 500. 
Initially, the toll free corp id list is retrieved 

30 from the server 2 02 via a "get hierarchy list" 
message. The toll free numbers are placed in 
appropriate boxes 562a, b,c, based on the flag returned 
with the hierarchy list, i.e., ' ' for corp ids, '8' 
for TFNM, and 'E' for enterprise. Corp ids in the 

35 corp id box 562a are those toll free corp ids for a 
given enterprise which have not been made TFNM 
participants and TFNM enterprise participants. The 
TFNM list 562b includes all toll free corp ids for a 
given enterprise that have been made TFNM 

40 participants. The enterprise list 562c includes all 
toll free corp ids for a given enterprise that have 
been made an enterprise level TFNM participant. Once 
the corp ids in the list are placed in the appropriate 
boxes, a user may then move the corp ids among the 

45 list boxes. For example, if a corp id is in the "corp 
id" list 562a, it may be moved to the "TFNM" list box 
562b. Corp ids in the "TFNM" list box 562b may be 
moved to the "enterprise" list box 562c. Pressing the 
submit button 564 causes a "set TFNM corpid" message 

50 to be sent to the StarOE server 202. The server 202 
then notifies and sends any corp ids moved among the 
list boxes to the mainframe registry. The corp ids 
are then added to the user's profile. Figures 21, 22, 
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and 24 illustrated screen displays for performing 
various order entry and administrative functions for 
the TFNM. Other application services, including 
reporting for VNET, Vision, Broadband, Call Manager, 
5 and invoice reporting may be ordered and the security 
infoirmation pertaining to each application may be 
modified in a similar manner. 

The screens illustrated in Figures 18-24 and 
associated class objects are invoked from the StarOE 

10 client application 204, which is launched by the 

backplane unit as described above. The StarOE client 
application 204 employs a Java application program and 
is implemented by extending the COApp class, one of 
common objects provided and utilized in the present 

15 invention. Because the client program 204 is not 

implemented as an applet, and also because the client 
program 204 employs the container Frame for customer 
display windowing purposes, the client program 2 04 
runs, to a degree, independent of the browser within 

20 which the backplane is deployed. 

The StarOE client application interacts with 
the StarOE server in providing various order entry 
functions for all applications as described above and 
will be: described below in reference to. the back-end 

25 functionality of the StarOE. Communications between 

the StarOE client 204 and the server 202 typically use 
TCP/IP, running a UNIX process listening in on a known 
TCP port. 

The StarOE server 

30 

The StarOE server 2 02 includes a number of 
processes for performing a number of specific 
functions. For example, a fulfillment process 
monitors new customers being added to the system and 

35 notifies a fulfillment house accordingly. The 
fulfillment house then may send appropriate 
subscription packages according to the information 
received from the fulfillment process to the new 
customer. Another process, a reconciliation process, 

40 may handle synchronization of data with a mainframe 
system database and also with databases associated 
with the individual fulfilling systems. Yet another 
process, a billing process, may handle directing 
billing information to different billing streams. 

45 The OE server 202 stores all the "networkMCI 

Interact" users and their security information such as 
passwords, application entitlements and hierarchies 
which may be requested by other application servers 
and clients in the network. Each user or customer is 

50 given a username and a password for accessing the 

"networkMCI Interact". In addition, during the order 
entry process, each user in the "networkMCI Interact" 
is provided with entitlement and hierarchies 
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describing the user's access privileges to specific 
application services and also to various sub -services 
available within the applications. 

Generally, the hierarchies are customer- 
5 defined during the order entry process, and describe 
the subdivision of calls into nodes arranged in a n- 
way tree. The "networkMCI Interact" back-end servers 
apply the hierarchy definitions to their data at 
report time when generating reports, typically as 

10 queries on a node -by -node basis to the result data set 
which was extracted using any other criteria supplied. 
The trees of the hierarchies have essentially 
arbitrary complexity, i.e., the number of nodes is 
unlimited. Each node is assigned calls according to a 

15 template of conditions. Conditions may be defined as 
a combination of one or more ANIs, corp IDs, ID codes. 
Card numbers, account codes, location/node ids, etc. 
These filters may be applied at any node in the tree. 
The hierarchies may be applied as both selection 

20 criteria (e.g., "report on all calls at these nodes or 
their descendants", in combination with other 
criteria) and roll-up targets (e.g., group the results 
in this report at this level in the tree) . These 
entitlepient and hierarchies may be modified via the 

25 StarOE client application executed in the customer 
workstation 204. 

An example of a service provided by the 
StarOE is an authentication process during a 
"networkMCI Interact" customer login procedure. As 

30 described above with reference to the StarOE client 

application, an initial access to the suite of network 
applications ("networkMCI Interact") is obtained 
through the Web pages invoking a login process and a 
backplane logic. The login process typically begins 

35 with a customer entering a username and password pair 
on an initial Web page retrieved from the Web site 
providing the suite of network applications. 
Referring to Figures 6 and 7, a process running in a 
client platform sends transaction request messages via 

40 the Dispatcher 206 to the OE server 202. The StarOE 

server 202 generally responds to requests by searching 
the security profile for the information requested, 
formulating appropriate transaction response messages 
and transmitting them back to the requesting process. 

45 More particularly, during the login procedure, the 

client login process formulates a transaction message 
including a user name/password and a validation 
request for a given customer. The StarOE server 202 
looks for the matching name/password pair in the 

50 security profile for the customer, and if the 

name/password pair is found, the server 202 formulates 
a valid user message response for the login process 
running in the client platform, including in the 
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message the enterprise id, time zone, and user id 
information, and transmits the response via TCP/IP 
back to the login process. In addition, each user 
password maintained in StarOE is set to expire at a 
5 predefined interval, e.g., every 90 days. 

Accordingly, when the StarOE server 202 detects that 
the password has expired, the server 202 notifies the 
customer, via the client application 204 to change the 
password. The changed password is sent to the StarOE 

10 server 20 2 formatted in a message interface, "change 
password request," for example. The server 202 upon 
receiving the message updates the password for the 
given user in its user profile typically stored in the 
database 314, and responds with appropriate return 

15 codes to the StarOE client 204. The login process, 

upon receiving the response may then continue with its 
normal course of processing. 

Another example of a service provided by the 
StarOE is retrieving an application entitlement list 

20 for a given customer. As described briefly above, an 
entitlement describes a privilege or authorization 
that a customer has. It is akin to the access levels 
in UNIX which are granted when a customer belongs to 
certain user: groups. It describes what applications a 

25 customer may access. It also describes what the 

customer may be allowed to do within that application. 
In addition, it describes what back-end services that 
application and customer combination may access. For 
example, a customer may be entitled to use or access 

30 many applications and for each application, the 

customer may have a different set of entitlements. 
These entitlements may come in two different sets. 
The first specifies what the customer may do with this 
application. For example, it may allow the customer 

35 to have update access to a particular view and only 

read-only access in a different view. The second set 
of entitlements specify what back-end services this 
particular application and customer may access. 

As described previously, all the information 

40 relating to entitlements for a given customer is 

stored in customer profile database 314 located with 
the StarOE server. When the backplane requests via 
TCP/IP the entitlement transaction, for example, in a 
get application list request message, the security 

45 module retrieves and transmits back via TCP/IP to the 
backplane the list of authorized applications 
accessible by a given customer in a transaction 
response. The backpl ane uses the list to determine 
which buttons on the "networkMCI Interact" home page 

50 should be activated, thus controlling access to 

products. Similarly, individual back-end application 
servers 208 may make a request for entitlements within 
that application for a given customer. For example, 
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the StarWRS, a "networkMCI Interact" reporting system, 
generates a request for hierarchy data for VNET, 
VISION, and Toll-free customers whenever reports need 
be generated. In response, the StarOE retrieves the 
5 corresponding hierarchy data and transmits them in 
real time to StarWRS. 

The Outbound Network Manager (ONM) , for 
managing the customer's private networks such as VNET 
and Vision networks, is another example of an 

10 application service having application specific 

customer entitlements defined and maintained in the 
StarOE database 314. For instance, the customers 
ordering ONM sign up at the corp id level. Each user 
may be associated with multiple corp ids. In 

15 addition, each user may have one or more of the 

entitlement features within ONM, including: CPN Order, 
Calling Card Order, Dialing Plan Order, ID Code Set 
Order to which orders a user's access may be permitted 
or restricted; Approve Order signifying approval 

20 authority in creating orders; Modify Order for 

defining user's authority to modify/ delete orders. 

In providing the authentication, 
entitlement, and hierarchy information, including 
those .described above, the StarOE server 2 02 includes 

25 the StarOE database 314 for storing user profiles 
locally- Additional data needed are typically 
accessed from the enterprise host systems 320. The 
StarOE server 202 may be implemented as a concurrent 
server allowing simultaneous multiple client 

30 connections. The server 202 listens on a known port, 
and when a client connects, the server 202 forks a new 
process to handle the client connection. The server 
202 may also implement a thread to handle each client 
connection . 

35 The StarOE server 202 may be implemented 

utilizing the object oriented programming (OOP) . At 
startup the oe_serv process instantiates an OEServ 
object, an OEConfig object, and a Logger object. The 
OEserv object is an instance of a main server class 

40 for starting the server processing including reading 
in the configuration and setting up the listening 
sockets. The OEConfig object is used to read specific 
StarOE configuration values, and the Logger object 
logs informational, warning, and/or error messages to 

45 a file. The OEConfig and Logger objects are typically 
set to Global so that all classes may access 
configuration values and log messages. The OEServ 
object then creates a Rogue Wave RWServerSocket object 
which creates a server socket connection and begins 

50 listening for client connections. The Rogue Wave 
Net++ library is typically used for socket 
communications . 
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The OEServ object includes a RWServerSocket 
object which waits to accept a connection from a 
client- When a client connects, a ClientHdlr object 
may be instantiated to handle the client connection. 
5 The ClientHdlr inherits from the Child class which 

when constructed, forks a new process for handling the 
client connection . 

The ClientHdlr object reads the message 
header and determines how much to read for the 
10 following message request which includes message 

request header and body. The message request is read 
and the message id is interrogated. A switch 
statement on the message id determines how the message 
may be processed. The proper classes may then be 
15 instantiated to handle the request and determine the 
response. When the response is determined by the 
proper class, the ClientHdlr then may create a message 
header and response header including a return code 
and/or an error code. The ClientHdlr then sends the 

20 message back to the client with the response. The 

ClientHdlr typically need not know the contents of the 
request or the response message, instead, the 
ClientHdlr may act as a conduit for passing messages 
from the ^client to a proper class to handle the 

25 request, and relay the response from the proper class 
back to the client. 

Some examples of the proper classes include 
the Tollf reeSecurity class, the Application class, and 
the Hierarchy class. In addition, the server includes 

30 many other classes for processing specific functions. 
The Tollf reeSecurity class encapsulates Tollfree 
security and access into the database tables having 
tollfree security detail information. When the 
ClientHdlr receives a Get User Tollfree Security 

35 request from the client, the Tollf reeSecurity class is 
instantiated. The Get ( ) method in this class access 
the database tables and returns the list of corp ids 
and tollfree numbers for this user. The ClientHdlr 
formats the data into a reponse message and returns 

40 the message back to the client. 

The Application class encapsulates the 
interface into the database table having applications 
information. Any reading or writing to this table may 
be handled by the methods within this class. When the 

45 ClientHdlr receives a Get Application Request, the 
Application class is typically instantiated. The 
GetO method in this class accesses the Applications 
table in the database and return the list of 
application codes and their descriptions. The 

50 ClientHdlr then formats the data into a reponse 

message and returns the message back to the client. 

The Hierarchy class encapsulates all 
hierarchy information and the methods to access this 
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data in the database. When the ClientHdlr receives a 
Get Hierarchy List request, the Hierarchy class is 
instantiated. The Get() method in this class 
determines which Hierarchy product is to be retrieved 
5 (e.g., Tollfree, Vnet/CVNS, or Vision) and returns the 
appropriate information. The ClientHdlr then formats 
the data into a response message and returns the 
message back to the client. The details of the 
message format, including request and response 
10 messages, are described with reference to Figure 13. 

Order entry process via StarOE 

Figure 10 is an illustrative example of an 

15 order entry process flow in the system of the present 
invention involving the functionalities described 
above. This process flow is used whenever a customer 
needs to interact with the StarOE system, whether it 
be as a new customer, or existing customer adding 

20 application services, or an existing customer changing 
individual passwords or work assignments for a 
specific application. The order entry process begins 
when a customer places an order for addition, 
modif ication :or deletion of services, as shown in step 

25 220. In step 222, an accounting team uses a new Web- 
based interface to enter the customer information. 
Typically, on a nightly basis, one or more e-mails may 
be generated to OEHub for Internet MCI access as shown 
in step 224, and to networkMCI Interact GEHubs as 

30 shown in step 232. At step 226, if the order is for a 
new customer, or if the existing customer needs a new 
browser package, then the OEHub handling Internet MCI 
service enters information from the e-mail to add or 
delete the customer. StarOE server then passes on 

35 mailing information to the fulfillment house, as 

indicated at step 228, which mails a package including 
the browser to the new customer to complete the 
process. The customer typically receives the browser 
package in 7-10 days. The fulfillment processing will 

40 be described in more detail with reference to Figure 
14. 

In step 234, the OEHubs enter data received 
from the e-mail. In step 236, if a new customer was 
added, the OEHubs add the customer information into 

45 the mainframe system via a direct interface as shown 
in steps 238 and 240. In steps 242 and 244, the new 
customer and service application information is added 
into the StarOE server database. 

In step 246, additional steps are performed 

50 by StarOE if necessary for each application. For 

example, if an added service is a Toll Free Network 
Manager (TFNM) , additional flags are tagged and stored 
in the application's server as shown in steps 248 to 



wo 99/15989 PCT/US98/20159 



258. In step 260, when the process of adding a new 
customer is complete, a fulfillment process, another 
component of the StarOE sends a welcome letter to the 
customer's inbox created as part of the addition 
5 process and transmits the new customer information to 
a fulfillment house as shown in steps 262 and 264. In 
step 266, the OEHub notifies account team that the 
order is complete. 

In response to the transmission from the 

10 fulfillment process, the fulfillment house, in step 

268, produces and mails a welcome letter that includes 
the user ID, a password to be used for the first logon 
and a list of applications the customer ordered. In 
step 270, if for any reason, the fulfillment process 

15 did not complete, a fulfillment representative 

contacts customer services, in step 272. In step 274, 
the customer services resolves issues by manually 
performing the fulfillment functions. 

In step 276, if new services were added by 

20 an existing customer, the services added are updated 
to the mainframe system. In step 278, the StarOE 
database is also updated with the additional services. 
In step 2 80, if a service application requires 
specif ic -added processing, for example,, the TFNM, the 

25 additional processing are performed in step 248 
through 266, as described previously. 

Figure 11 is a high level input process flow 
diagram, illustrating inputs to the system of the 
present invention. The present invention handles a 

30 wide variety of key function for the suite of network 
applications. Each application will, herein forth, be 
also referred to as a fulfilling system, having a 
fulfilling client and a fulfilling server. The system 
of the present invention handles security and 

35 authentication requests from both the client and 

server sides of each fulfilling system as shown in 
282a -d and 284. These requests are automatically 
generated whenever the customer makes a request of the 
server. For example, they are generated when a 

40 customer clicks on the icon for a service such as 
TFNM. 

In addition, when a customer first logs on, 
the customer is presented with a dialog box prompting 
for user ID and password. When the customer clicks a 

45 submit button, for example, the backplane (or 

platform) verifies the customer is valid by inquiring 
with the StarOE system as shown in 286. The return 
response is either "invalid user/password" or "valid 
user". When the customer has been authenticated, the 

50 customer is then presented with a list of authorized 

applications. This list determines which buttons, for 
example, representing each application are active. 
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thus controlling customer access to products and 
services . 

In addition, also shown in 286, the customer 
is issued a temporary password with the customer's 
5 fulfillment package. This temporary password is used 
to log into the system the first time. During the 
initial logon process, the customer is prompted to 
create a new password, which replaces the temporary 
password in the database. Moreover, the customer may 

10 be required to change the password every 30 days, for 
example, for security reasons. 

Information may also be entered and 
requested by a number of sites other than a user 
platform. For example, OE Hubs 288 may enter 

15 information directly into the StarOE database to 
register new customers to the integrated suite of 
network applications. They may also access the data 
in StarOE directly to modify customer information, and 
to add or remove subscribed services. 

20 Other inputs to the StarOE server may 

include entitlement data from the individual 
fulfilling systems 290a, 290b. For example, the 
mainframe 290a may send the appropriate hierarchy of 
tollf ree :,numbers for a specific customer in response 

25 to registry message registering the new customer to 

the mainframe 290a. The hierarchy of tollf ree numbers 
describes the new customer's entitlements to the TFNM 
services. This hierarchy may be used by other 
services in the integrated suite of network 

30 applications, for example, a Reporting application. 

As described above, the StarOE is a 
repository for customer authentication and entitlement 
information. These authentication and entitlement 
data are usually transmitted from mainframe systems 

35 292, 292a, 292b. For example, the mainframe system 
292 generates two sets of hierarchy files on a daily 
basis. One set comprises deltas only, the other 
comprises a full hierarchy. Notification is made to 
the StarOE when these are available. At a set time 

40 each day, for example, 6:00 A.M., the StarOE, the 

reconciliation process more specifically, picks up the 
files via FTP and either replaces the previous day's 
hierarchy file with the new information (full file) or 
updates the previous day's file using the files having 

45 the updated data only. During this process, the 

reconciliation process first locks the database so 
that no other requests for data services may be made. 

Figure 12 is an output process flow diagram, 
illustrating outputs from the system of the present 

50 invention. The StarOE outputs various responses to 
the requesting systems and processes. An example of 
an output is an authentication response to the client 
side of the individual applications 292a-c as well as 
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the backplane platform 294. In addition, a list of 
accessible applications for a given customer, is 
output to the backplane platform 294. The StarOE also 
outputs various updated data to database systems 
associated with specific individual applications 296a- 
c in the suite of network applications. In addition, 
the individual fulfilling systems 302a-d receive 
messages from the StarOE regarding modifications 
effected by a customer interaction. For example, as 
part of the reconciliation process, the StarOE may 
pass a list of toll free numbers to be deleted from 
Traffic View. These numbers represent the services 
which are discontinued. Upon receipt of this 
information, the Traffic View server sends another 
message to a system responsible for collecting call 
detail information which system then discontinues 
collection of call data for the numbers deleted. 
Another example output to individual fulfilling system 
is hierarchy data to Reporting fulfilling system 203c 
when a customer requests reports. The customer 
hierarchy data is sent in real time by the StarOE for 
up-to-date report information. 

Additionally, the fulfillment house receives 
transactions ^ from the StarOE. The StarOE, for 
example, by a fulfillment process, pushes a file 
including new customers to the fulfillment house 298, 
for instance, via FTP. This file includes customer 
mailing information, user name and password. The 
fulfillment house 298 creates a welcome package 
including the customer's user name and temporary 
password, and sends the package. The customer 
receives this package and uses the temporary password 
to logon to the system of integrated suite of network 
applications the first time. During the initial logon 
process, the user may be prompted to create a new 
password, which replaces the temporary password in the 
StarOE database. Upon logon, the user may find 
another welcome letter which lists the subscribed 
applications. This welcome letter was generated by 
StarOE server via e-mail when the order entry process 
was completed, and went to the Inbox 300 at that time. 
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StarOE transaction messages 

Figure 13 illustrates message formats used 
in transaction requests and responses communicated to 
5 and from the client and server applications in the 
system of the present invention. As described with 
reference to Figure 6, the client applications 
typically send messages to the StarOE via the 
dispatcher 206 Figure 6. The messages are generally a 
10 stream of bytes including characters and each message 
typically has an order and format. The messages may 
also include fields of primitive types such as int or 
short - 

The client applications, typically 

15 implemented in languages such as Java, encapsulate the 
message structures into class object. The application 
server programs including the StarOE, typically 
implemented using low level compiler languages such as 
C or C++, receives the message objects from the client 

20 applications as a stream of bytes and map the message 
objects into appropriate C structures. Typically, all 
the structures are aligned on byte boundary, byte 
aligned and in network byte order, so that Java 
objects/ may be mapped correctly into the C structures 

25 on the StarOE. , 

The StarOE messages have fixed formats. For 
example, for a request transaction, the request 
message 3 08 is preceded by a message header 3 04a and a 
request header 306. A response message 312 is 

30 preceded by a message header 304b and a response 
header 310. 

The message header 304a, 304b is sent as the 
first part of all messages sent to or from the StarOE 
so that the receiver may know the size of the message 

35 being sent. This mechanism allows the server or 

client to read the proper number of bytes. When the 
OE server receives a message, a communications layer 
of the StarOE strips off the message header structure 
and adds it to all responses associated with this 

40 message. 

The request header 306 follows the message 
header 3 04a on all messages sent to the StarOE. The 
StarOE examines the request header 306 for 
determining the type and version of message. It 

45 allows the StarOE to map the message to the correct C 
structure for subsequent processing. Similarly, 
response header 310 follows the message header 304b on 
all messages sent from the StarOE. The response 
header 310 precedes all response messages. 

50 The StarOE client program typically 

implements message transactions using class objects. 
Figure 9 illustrates messages class diagram utilized 
in the present invention. The messaging classes 570 
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hide the complexities involved in issuing a 
transaction to the StarOE. Common functions are 
implemented in the base message classes encapsulating 
much of the effort required to build message classes. 
5 Message classes are created generally for requests and 
responses distinctly. 

The request and response classes derive from 
the common base class OEMsg 572. The class OEMsg 572 
encapsulates the common message header required by the 

10 StarOE. The classes OERqstMsg 574 and OERspMsg 576 
serve as common base classes for the request and 
response messages respectively. All request messages 
also implement the COMessage interface. COMessage 
functions provide the necessary hooks to send and 

15 receive messages from the client platform to the back- 
end application servers. All StarOE messages use the 
synchronous transaction mechanism, wherein the 
transactions block until a response is received. 

The following codes illustrates retrieval of 

20 user information using the order entry message 
classes . 

OEUsrInf oRqst usrinfo = new 

OEUsrInf oRqst { "abecar" , session) ; 
if^ (usrinfo. dolt 0 == true) .{ 
25 OEUsrInf oRsp uinfo = 

(OEUsrIhfoRsp) usrin 
fo.getResponseObj () 

OEUsrInf o info = uinfo .getUsrInfoObj () ; 
30 System.out.println ("First name:" 

+info. f irstName) ; 

} 

else 

System. out .println( "Failed to retrieve 

35 user information"); 

Once a request object is built, the method 
doItO on the OERqstMsg 574 class must be invoked to 
initiate the transaction. The method doItO may block 
until a response is received. A boolean return code 

40 is returned by doItO . To obtain the response data or 
detailed error code information the method 
getResponseObj () must be invoked to return the built 
response object. 

Specific transaction messages communicated 

45 in the system of the present invention include 
"validate user message" for authenticating the 
customer's username/password pair, "get user 
application list message" for retrieving a list of 
applications to which the customer is entitled, and 

50 "update password message" for changing the customer's 
password. These transaction messages are typically 
communicated between the StarOE and the backplane 
unit. These messages may also be used by other 
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application services to verify entitlements in the 
event an extra level of security is desired. 

Examples of transaction messages 
communicated between the StarOE server and the StarOE 
5 client include "get user info'' for retrieving 

customer's information such as name, address, timezone 
for the location of the customer. Another example of 
a transaction message communicated to the StarOE 
system by all the application clients and servers may 

10 be a "get user security message" for retrieving 

customer's security information including the userid, 
usertype which describes whether the customer is a 
regular user or an administrator, and access id for 
describing the customer's access level. The system of 

15 the present invention includes a number of such 

transaction messages described above for specific type 
of requests and responses communicated to and from the 
OE system and, moreover, additional message specific 
transactions may be added as necessary. 

20 

StarOE interface to fulfillment house 

Figure 14 is a diagram illustrating data 
flow interface with the fulfillment house in the 

25 system "of the present invention. Generally, customers 
are added by Order Entry, via StarOE client program 
316. A fulfillment process typically sends 
information on new customers to the fulfillment house 
29 8 on a nightly basis and also sends a news message 

30 comprising welcome letters to each new customer via 
the Inbox 300. If a new application is added to an 
existing customer then only a message is sent to the 
customer via the Inbox 300. 

The fulfillment kit comprises a welcome 

35 letter and an inbox message. The fulfillment process 
in the StarOE server 202 typically runs on a daily 
basis. The information needed for the fulfillment 
process is generally stored in a database 314, 
Informix for example, in table forms. Such tables may 

40 include a user, configuration, and enterprise user 
application tables. The information or data is 
retrieved, configured and computed from the tables and 
put into a temporary fulfillment table which is used 
for the collection of the fulfillment information. 

45 From the fulfillment table the process creates the 
inbox letters and records for the fulfillment file. 
The enterprise user application table usually includes 
the status of whether the requested applications have 
been fulfilled. The fulfillment file is transferred, 

50 using file transfer protocol (FTP), for example, to 

the fulfillment group 29 8 for creation of the welcome 
letters . 
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Figure 8 illustrates an example of a welcome 
letter 80. The welcome letter 80, which is in a 
language that the customer requested, comprises the 
customer's id and password, URLs pointing to a 
5 language specific Web page where a customer may 

typically start up the system of the present invention 
which the customer has ordered. 

StarOE interface to StarWRS 

10 

Figure 15 is a diagram illustrating data 
flow interface with the Reporting application. The 
Reporting application is one of the applications 
available as part of the integrated suite of network 

15 applications. Figure 15 shows StarOE server's 

interface to various systems in order to provide the 
Reporting application the appropriate information for 
producing reports. The reconciliation process 
generally loads data, such as the toll free 

20 hierarchies and pick list information in the StarOE 

database from the mainframe systems 320. The data are 
required to setup the security profile for the 
Reporting application. The loading may be performed 
periodically^ for example, on a nightly basis. 

25 The StarOE client 316 may modify a 

customer's Reporting Application security profile and 
add, update, or delete the application and hierarchy 
access. The hierarchy and security are stored in 
StarOE database 314. When a customer modifies the 

30 customer's Reporting Application security profile, a 

select set of data are sent to appropriate servers for 
real time processing. For example, if the modified 
security profile includes Un -priced Reports, then the 
records in the security profile with these reports are 

35 sent in realtime to the Traffic View Server 322, such 
that the Traffic View Server 322 may begin collecting 
data as soon as the customer makes the modification. 

A Reporting application's client program, 
report requester 324a as well as the servers 324b, 

40 324c also retrieves a customer's profile for reporting 
purposes. For example, a report scheduler 324b, a 
part of the reporting servers, verifies via a direct 
connection with the StarOE database 314, the 
customer's access level to the hierarchy before 

45 scheduling report requests. The Inbox server 300a also 
requests paging and e-mail information from StarOE 
server 202 for optional report notifications. 
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StarOE interface to TFNM 

Figure 16 is a diagram illustrating the data 
flow interface with the Toll Free Network Manager 
5 application. The Toll Free Network Manager is one of 
the applications available as part of the integrated 
suite of network applications. Figure 16 shows StarOE 
server's interface to various systems in order to 
provide the Toll Free Network Manager application the 

10 appropriate information toll free servicing ♦ The data 
hierarchies necessary for the Toll Free Network 
Manager are retrieved by the reconciliation process 
via FTP nightly, for example, from the mainframe 
system 320 and stored in the StarOE database 314. The 

15 data hierarchies retrieved are used to setup the 

security profile for the Toll Free Network Manager 
application 326a, 326b. Information setup in the 
security profile are sent to the mainframe systems 320 
by the StarOE server 202. For example, the corp ids 

20 that are setup at a global level in StarOE database 
314 for use by the Toll Free Network Manager 
application represent participants of the Toll Free 
Network Manager and are flagged as such in the 
mainframe system when the information is received. 

25 Therefore, upon receiving the ids the mainframe system 
32 0, for any reason, may not delete these corp ids 
while they are flagged. Additionally, the Toll Free 
Network Manager server 326a sends requests to the 
StarOE server 314 to get a Toll Free Network Manager 

30 customer's security. This is done by formulating a 

get user security message in a transaction request as 
described in reference to Figure 13 . 

StarOE interface to Broadband 

35 Figure 17 is a diagram illustrating data 

flow interface with the Broadband application. The 
Broadband is one of the applications available as part- 
of the integrated suite of network applications. 
Figure 17 shows the StarOE server's interface to 

40 various systems in order to provide the Broadband 

application the appropriate information for broadband 
servicing. Customer's user and security profile for 
the Broadband application is added by Order Entry 330. 
When a Broadband customer's profile is added, changed, 

45 or deleted, the Broadband server 328a needs to be 

notified of the operation so that the server 328a can 
either begin or stop collecting data for the specific 
customer's bill ids. Typically the notification is 
done by a message in the form of a file. The file is 

50 typically placed in a known directory and is 

transferred to the Broadband server 328a via FTP 
process. The file transferred generally includes all 
the current Broadband customers with their bill ids. 
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While the invention has been particularly 
shown and described with respect to preferred 
embodiments thereof, it will be understood by those 
skilled in the art that the foregoing and other 
changes in form and details may be made therein 
without departing from the spirit and scope of the 
invention. More specifically, the system 
administrative and order entry system described may 
apply to any generic applications available via the 
Web and is not limited to the telecommunications 
applications explained above for exemplary purposes. 
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CLAIMS 

What is claimed is: 



1 !• A Web -based centralized authentication 

2 and entitlement administration system for enabling a 

3 customer to enter orders over the Internet from a 

4 client terminal for one or more application services 

5 available at an enterprise, the system comprising: 

6 a client browser application located at 

7 the client terminal and providing an integrated 

8 interface to the one or more application services, the 

9 client browser application interacting with the 

10 customer; 

11 an order entry server located at the 

12 enterprise, the order entry server for communicating 

13 over the Internet with the client browser application 

14 to provide authentication and entitlement information 

15 associated with the customer, wherein the client 

16 browser application obtains the authentication and 

17 entitlement information associated with the customer 

18 and applies the authentication information in 

19 validating the customer before enabling the customer 

20 to access the enterprise, the client browser 

21 application enabling the customer to access only those 

22 application services to which the customer is 

23 entitled; and 

24 an order entry object initiated by the 

25 client browser application, for enabling presentation 

26 of entry options for the customer, the entry options 

27 including adding a new order entry, modifying an 

28 existing order entry, and canceling an order entry, 

29 the order entry object further communicating customer 

30 entry of a specific entry option to the order entry 

31 server, 

32 whereby the customer is enabled via the 

33 integrated interface to enter new orders, modify 

34 existing orders, and cancel orders for the application 

35 services within the customer entitlements. 

1 2. The system as claimed in claim 1, 

2 wherein the order entry server further comprises a 

3 customer profile database for storing the 

4 authentication and entitlement information. 

1 3. The system as claimed in claim 1, 

2 wherein the order entry object further comprises a 

3 first device for communicating new order entries, 

4 modified entries, and canceled order entries in 

5 response to customer entry of a specific option, and 

6 wherein the order entry server further comprises a 

7 device for accepting and storing. the customer entries. 
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1 4. The system as claimed in claim 3, 

2 wherein the first device for communicating comprises a 

3 plurality of messaging classes, the plurality of 

4 messaging classes including: 

5 base message classes for encapsulating 

6 standards required for communicating between the 

7 client browser application and the order entry server; 

8 request and response classes derived 

9 from the base message classes for handling a plurality 

10 of request and response transactions communicated 

11 between the client browser application and the order 

12 entry server, which request and response transactions 

13 include the new order entries, modified entries, and 

14 canceled order entries associated with the customer 

15 selection of a specific option. 

1 5. The system as claimed in claim 1, 

2 wherein the order entry object includes an entry 

3 application downloaded from the enterprise, the entry 

4 application running in its own window frame. 

1 6. The system as claimed in claim 2, 

2 wherein the order entry server further comprises a 

3 fulfillment process for retrieving from the customer 

4 profile information associated with newly added 

5 customers, and wherein the fulfillment process 

6 notifies and electronically transmits the information 

7 to a fulfillment house responsible for sending 

8 subscriptions packages to new customers. 

1 7. The system as claimed in claim 6, 

2 wherein the fulfillment process runs periodically on a 

3 pre-defined time basis. 

1 8. The system as claimed in claim 6, 

2 wherein the fulfillment process further sends the 

3 subscription packages with a welcome message to a 

4 message center created for and associated with the new 

5 customers. 

1 9, The system as claimed in claim 2, 

2 wherein the order entry server further comprises a 

3 reconciliation process for updating and synchronizing 

4 data stored in the customer profile with data stored 

5 in mainframe systems. 

1 10. The system as claimed in claim 9, 

2 wherein the reconciliation process runs periodically 

3 on a pre-defined time basis. 

1 11. The system as claimed in claim 9, 

2 wherein the reconciliation process further updates and 

3 synchronizes the customer profile data with data 
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4 stored in servers associated with the application 

5 services . 

1 12. The system as claimed in claim 11, 

2 wherein the reconciliation process updates and 

3 synchronizes data in real time, wherein the 

4 application services use real time data when 

5 processing requests by the customer. 

1 13. The system as claimed in claim 2, 

2 wherein the order entry server further comprises a 

3 billing process for automatically directing customer 

4 bills to a billing stream specified in the customer 

5 profile. 

1 14. The system as claimed in claim 2, 

2 wherein the order entry object presents the entry 

3 options in a tree format. 

1 15. The system as claimed in claim 14, 

2 wherein a first tree level represents an enterprise, a 

3 second tree level represents users under the 

4 enterprise, and a third tree level represents 

5 application services accessible by the users. 

1 16. The system as claimed in claim 15, 

2 wherein the second tree level further comprises a new 

3 user node for enabling addition of a new user under an 

4 enterprise. 

1 17. The system as claimed in claim 14, 

2 wherein a first tree level represents an enterprise, a 

3 second tree level represents a corp, and a third tree 

4 level represents toll free numbers subscribed by the 

5 corp . 

1 18. The system as claimed in claim 14, 

2 wherein the order entry object enables modification of 

3 entries associated with a node in the tree when the 

4 node selected. 

1 19. The system as claimed in claim 18, 

2 wherein the modification of entries includes modifying 

3 reporting options for toll free numbers. 

1 20. The system as claimed in claim 18, 

2 wherein the modification of entries includes modifying 

3 user access levels associated with the application 

4 services . 

1 21. The system as claimed in claim 18, 

2 wherein the modification of entries includes modifying 
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3 target billing streams where customer bills are 

4 transmitted. 

1 22. A method of providing Internet enabled 

2 centralized authentication and entitlement 

3 administration services for enabling a customer to 

4 enter orders over the Internet from a client 

5 workstation for one or more application services 

6 available from an enterprise, the method comprising: 

7 presenting to a customer a client browser 

8 application having an integrated interface to the one 

9 or more application services; 

10 communicating authentication requests and 

11 responses over the Internet to an order entry server 

12 located at the enterprise; 

13 authenticating the customer at the client 

14 workstation with authentication information received 

15 from the order entry server; 

16 enabling the customer to access 

17 predetermined application services according to an 

18 entitlement response received from the order entry 

19 server; 

20 enabling presentation of entry options for 

21 the customer^ the entry options including adding a new 

22 order entry, modifying an existing order entry, and 

23 canceling an order entry; and then 

24 communicating customer selected entry 

25 • options to the order entry server, 

26 wherein the customer is enabled via the 

27 integrated interface to enter new orders, modify 

28 existing orders, and cancel orders for the application 

29 services within the customer entitlements. 

1 23. The method according to claim 22, 

2 wherein the method further comprises: 

3 storing authentication and entitlement 

4 information in a customer profile database at the 

5 enterprise. 

1 24- The method according to claim 22, 

2 wherein the method further comprises updating and 

3 synchronizing the customer profile database with data 

4 in at least one mainframe system providing an 

5 application service to the customer. 

1 25. The method according to claim 22, 

2 wherein the method further comprises transmitting data 

3 associated with a customer selected entry option to a 

4 server associated with a respective application 

5 service. 



-44- 



wo 99/15989 



PCTAJS98/20159 



1 26. The method according to claim 22, 

2 wherein the method further comprises presenting entry 

3 entitlements to the customer in a tree format. 

1 27. The method according to claim 23, 

2 wherein the method further comprises directing 

3 customer bills to billing streams specified in the 

4 customer profile database. 
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Colorado Springs, CO 80919 



Junel. 1998 



Biyan Fenley 
MCI 

2424 Garden of the God 
Colorado Springs, CO 80919 

Enterprise ID: 10379399 

Dear networkMCI Interact^^ Subscriber, 

Welcome to networkMCI Interact. Now you have everything you need to monitor and manage your 
company's MCI services via the World Wide Web.* 

To access networkMCI Interacts integrated suite of applications, you must have Inlemct access. For your 
convenience, we are sending you Internet access software under separate cover in case you currently do not 
have an Internet Service provider. 

Because you are a networkMCI Interact Subscriber, we are offering you FREE unlimited local Internet 
access when you register for networkMCI Imemct*"— a savings of $19.95 per month! Each nKmth, this 
amount will appear oo your invoices as a fiill credit. In addition 800/888 toll-free access is also available at 
the fate of 85.95 per hour. When you receive your networkMCI Internet CD-ROM package, simply refer 
to the Gettmg Started Guide for instructions on how to install and register for networkMCI Intemct.*** 

Once you have access to the Internet, you must k>g-on to the networkMCI Interact Web site, 
httDs:y/www.intcract.mci.com. using the personal User ID and Temporary Password listed below. 

LOG-ON INFORMATION 



User ID: tollfree 

Temporary Password: password 

When you first log-on to the networkMCI Interact home page, instructions will be provided for 
personalizing your password. Also, for more information pertaining to the applications you have ordered, 
simply go to the Message Center located on the networkMCI Interact home page. 

If you have questions or need technical support for networkMCI Interact, please call I -800-326-2775. For 
networkMCI Internet technical support, please call 1-800-326-2775. For a complete listing of applications 
available through networkMCI Interact, please contact your MCI account representative. 

Thank you for choosing networkMCI Interact. 



Sincerely, 



Ronald J. McMunrie 

Vice President, Product. Local, and Global Maiketmg 

♦ MO'i lnt»m«t bfOv«ff utilliw Mlaoieft Intirnci Ciplorcf wWeh h • rcglttcrcd trademark of wiitrofoft Corporation In tht 
UfvtM) States and for other countriei. 

••rt you thooftt to UM a bioMier other than iwtworltMa 4.0? or Mkrojoft Internet bplorer 4.01, cannot gutraniec the 
pcffDrnMrK« of, or provide te<hnkal lupport tor that loftware. 
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